Traditionally, application and services have been hosted by on-premises data centers. However, the traditional on-premises hosting paradigm is costly because customers incurred expenses to develop and maintain the hardware and software associated with the on-premises data centers. As such, there has been a trend toward moving applications and services to third-party providers (e.g., cloud services) that support computing models such as, Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). These models service to reduce costs, as the customer no longer no longer needs to host and manage their own data center.
However, moving applications and services to third-party providers has several major risks. For example, the move must be done all at once as it is difficult to move portions of the business logic of the applications and services to third-party providers without impacting the whole system. There are also concerns about vendor “lock-in” as writing code to a third-party's API may make it difficult to move when the third-party provider raises prices. In addition, moving to a new third-party provider can be costly. For example, such moves often require help from highly paid consultants. There are training issues with third-party providers, as the customer's developers likely have deep knowledge of their own on-premises APIs, but do not have a full understanding of the target APIs of the third-party provider. The training issue is compounded if the customer decides to use multiple third-party providers, as the customer's developers will have to maintain knowledge of several APIs.
Further, PaaS is a relatively new technology and code written correctly against a particular API can break if that API changes or is depreciated. Scaling issues make it unfeasible to scale-up the large numbers of service offerings as they multiply. That is, the tracking of resources against applications becomes extremely complex, as an application may access dozens of resources, some of which may change or move during the application's lifespan. Configuration and environment identifiers are bound tightly to the deployed code, which causes severe problems as the number of modules of code increases. That is, the code no longer exists in just a few deployment modules. Finally, configuration management is still practiced as if it is old on-premises and has not evolved with the third-party provider hosting paradigm.
Thus, there is a need for an PaaS architecture that provides a solution to the limitations of conventional solutions.